Hi @maxwang789 thanks for your interest in the project.
I think that this a deviation from MQTT protocol, all client subscribed to topics that matches the topic on which publish is done, has to be notified of a message. The MQTT 3.1 and MQTT 3.1.1 doesn't specify anything of this shape, so could be considered a break of the protocol.

Hi @maxwang789 thanks for your interest in the project. I think that this a deviation from MQTT protocol, all client subscribed to topics that matches the topic on which publish is done, has to be notified of a message. The MQTT 3.1 and MQTT 3.1.1 doesn't specify anything of this shape, so could be considered a break of the protocol.

HI @andsel You are correct, this is not part of MQTT specification.
But we are facing some old equipment which already implemented such mechanism.
We have no choice by to adopt this legacy interface.
And in the same time we should try not make any side effect to normal user which follow MQTT spec.
This method only available inside an embedded server, the external subscriber/publisher could not access it and they will not notice any change.

Hi @maxwang789 I understand your reason, but internalPublish is an API method that Server provides to it's consumers. So the ask here is to modify a published API intended to respect the MQTT protocol to satisfy a specific request that's outside the protocol specification.
If you provide any number of valid use cases would be helpful , because as I can understand it so satisfy your specific requirements.
Having more context, for example which devices claims to be MQTT compliant (while in reality they aren't) and if it solves a specific use case or is more general, would help understand if it worthwhile to go outside of specs or not.
For example, I don't know if other brokers implements such customizations.